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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 



This Technical Specification (TS) has been produced by ECMA on behalf of its members and those of the European 
Telecommunications Standards Institute (ETSI). 



Brief history 



The present document is one of a series of ECMA standards defining mapping functions in exchanges of Private 
Integrated Services Networks required for the utilization of intervening network scenarios. The series uses the ISDN 
concepts as developed by ITU-T (formerly CCITT) and is also within the framework of standards for open systems 
interconnection as defined by ISO. It has been produced under ETSI work item DTS/ECMA-00233. 

The present document specifies mapping functions for the type of scenarios where two or more PINXs are 
interconnected via on-demand connections using an H.323 packet network as the IVN. 

The present document is based upon the practical experience of ECMA member companies and the results of their 
active and continuous participation in the work of ISO/IEC JTC1, ITU-T, ETSI and other international and national 
standardization bodies. It represents a pragmatic and widely based consensus. 

The present document has been adopted by the General Assembly of December 2001. 
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Scope 



The present document specifies functions for using an H.323 packet network in order to interconnect two Private 
Integrated services Network exchanges (PINXs) forming part of a Private Integrated Services Network (PISN). 
Interconnection is achieved by carrying the inter-PINX signalling protocol over the H.323 call signalling channel, 
making use of the protocol tunnelling facilities of H.323, and inter-PINX user information (e.g., voice) over logical 
channels established through H.323. Each logical channel usually represents a unidirectional media stream conveyed by 
means of the Real-time Transport Protocol (RTP). The inter-PINX signalling protocol is assumed to be QSIG, as 
specified in ECMA-143 [2], ECMA-165 [3] and other standards. 

The present document provides for an on-demand type of interconnection, where a separate H.323 call is established at 
the start of each PISN call and cleared down at the end of that call. A semi-permanent scenario where a single H.323 
call with an indefinite lifetime carries QSIG on behalf of many PISN calls is described as an additional option. 

In the scenarios covered in the present document, the PINXs participating in a call are not necessarily aware of the 
H.323 network providing the interconnection, and the features available are those of the QSIG network. This is different 
from a scenario where true interworking between QSIG and H.323 (i.e. QSIG-H.323-QSIG) is used to connect two 
PISNs or two parts of the same PISN. In this latter case all networks participate in a call on equal terms, and features are 
limited to those available in all networks and supported by the gateways. This latter scenario is outside the scope of the 
present document. 

The present document is applicable to PINXs that can be interconnected to form a PISN using QSIG as the inter-PINX 
signalling protocol. 



Conformance 



In order to conform to the present document, a PINX shall satisfy the requirements identified in the Implementation 
Conformance Statement (ICS) proforma in annex A. 



3 References 

The following standards contain provisions which, through reference in this text, constitute provisions of the present 
document. All standards are subject to revision, and parties to agreements based on the present document are 
encouraged to investigate the possibility of applying the most recent editions of the present documents indicated below. 

In the case of references to ECMA Standards that are aligned with ISO/IEC International Standards, the number of the 
appropriate ISO/IEC International Standard is given in brackets after the ECMA reference. 

[1] ECMA-133: "Private Integrated Services Network (PISN) - Reference Configuration for PISN 

Exchanges (PINX) (International Standard ISO/IEC 1 1579-1)" . 

[2] ECMA-143: "Private Integrated Services Network (PISN) - Circuit Mode Bearer 

Services - Inter-Exchange Signalling Procedures and Protocol (QSIG-BC) (International Standard 
ISO/IEC 11572)". 

[3] ECMA-165: "Private Integrated Services Network (PISN) - Generic Functional Protocol for the 

Support of Supplementary Services - Inter-Exchange Signalling Procedures and Protocol 
(QSIG-GF) (International Standard ISO/IEC 1 1582)". 

[4] ITU-T Recommendation H. 225.0: "Call signalling protocols and media stream packetization for 

packet based multimedia communications systems". 

[5] ITU-T Recommendation H.245: "Control protocol for multimedia communication". 

[6] ITU-T Recommendation H.323: "Packet based multimedia communications systems". 

[7] ITU-T Recommendation H.323 annex M.l: "Tunnelling of signalling protocols (QSIG) in H.323". 
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4 Definitions 

4.1 External definitions 

For the purposes of the present document, the following terms and definitions apply: 
Call independent signalling connection (ECMA-165 [3]); 

- C reference point (ECMA- 1 33 [ 1 ]); 
Gatekeeper (ITU-T Recommendation H.323 [6]); 

Gateway, Trunking Gateway (ITU-T Recommendation H.323 [6]); 

- Intervening network (ECMA- 1 3 3 [ 1 ] ) ; 

Logical channel (ITU-T Recommendation H.323 [6]); 

- Preceding PINX (ECMA-165 [3]); 

- Private Integrated Services Network (ECMA-133 [1]); 
Private Integrated services Network eXchange (ECMA-133 [1]); 

- Q reference point (ECMA- 1 3 3 [ 1 ] ) ; 

- Subsequent PINX (ECMA-165 [3]). 

4.2 Other definitions 

For the purposes of the present document, the following terms and definitions apply: 

4.2.1 Call 

4.2.1.1 H.323 call 

A call as defined in ITU-T Recommendation H.323 [6], i.e. a point-to-point communication between two H.323 
endpoints. Here specifically a call in the H.323 network between two gateways. 

4.2.1.2 PISNcall 

A call as defined in ECMA-143 [2] and ECMA-165 [3]. 

4.2.1.3 Call segment 

A portion of a (PISN) call between two entities taking part in that call. The smallest segment is between adjacent 
entities, e.g. between two PINXs across one Inter-PINX link. 

4.2.2 Channel 

A means of bi-directional transmission of user or signalling information between two points. 

4.2.2.1 Da-Channel 

A channel used to convey call control information between the Q reference points of two peer PINXs. 
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4.2.2.2 UcrChannel 

A channel used to convey user information between the Q reference points of two peer PINXs. 

4.2.3 Inter-PINX Connection (IPC) 

A connection provided by an IVN between two C reference points used to transport inter-PINX information from the 
PISN control plane and/or the PISN user plane. 

4.2.4 Inter-PINX Link (IPL) 

A link between the Q reference points of two PINXs, comprising the totality of signalling transfer and user information 
transfer means. 

4.2.5 PINX roles 

4.2.5.1 Initiating PINX 

The PINX that initiates an IPL establishment request. 

4.2.5.2 Accepting PINX 

The PINX that accepts an IPL establishment request. 



Acronyms 



GK GateKeeper 

ICS Implementation Conformance Statement 

IP Internet Protocol 

IPC Inter-PINX Connection 

IPL Inter-PINX Link 

IVN Intervening Network 

PINX Private Integrated services Network eXchange 

PISN Private Integrated Services Network 

QSIG Q Interface Signalling Protocol 

RAS Registration, Admission and Status 

RRQ Register ReQuest message 

RTP/RTCP Real Time Protocol/Real Time Control Protocol 

TCP Transmission Control Protocol 

UDP User Datagram Protocol 



Introduction 



6.1 Reference configuration 

ECMA-133 [1] defines a reference configuration for a PINX. Logically the switching and call control functions of a 
PINX communicate over an instance of the Q reference point with a peer PINX. This communication is known as an 
Inter-PINX Link (IPL) and comprises a signalling channel, known as a Dg-channel, and one or more user information 

channels, each known as a UQ-channel; see figure 1. One or more IPLs can be established between the same pair of 

PINXs. 
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Figure 1 : IPL concept 

There are many ways of implementing an IPL. In general, the IPL uses services of another network, known as an 
Intervening Network (IVN). A PINX interfaces to the IVN at the C reference point. The IVN provides connections, 
known as Inter-PINX Connections (IPCs) between the C reference points of the peer PINXs. Mapping functions within 
each PINX map the DQ-channel and the Ug-channels at the Q reference point onto one or more IPCs at the C reference 
point. 

6.2 Specific scenarios 

The present document specifies mapping functions for use when the IVN is an H.323 packet network that is used to 
provide the following types of IPC: 

• a signalling connection for carrying signalling information; and 

• a pair of UDP streams, one stream in each direction, for carrying user information over RTP. 

NOTE: Other means of transporting user information can be used, e.g. T.38 fax without RTP, an ATM virtual 
channel, or a bi-directional TCP connection instead of UDP streams. See ITU-T Recommendation 
H.323 [6] for more details. These cases are outside the scope of the present document. 

A single IPL requires a single signalling connection, for support of the DQ-channel, and one pair of UDP streams per 
UQ-channel. 

The main inter-PINX connection scenario described in the present document is an on-demand connection scenario. This 
means that an IPL is established whenever a PISN call segment is to be set up between two PINXs and released when 
the PISN call ends. An optional semi-permanent scenario is also described, where multiple concurrent or consecutive 
PISN calls can use the same IPL. 

In both scenarios the signalling connection is established by means of an H.323 call, using the protocol tunnelling 
facilities provided by ITU-T Recommendations H. 225.0 [4] and H.323 annex M.l [7]. The H.225.0 call signalling 
connection in conjunction with the tunnelling of the QSIG signalling is used to provide the DQ-channel. The pair of 

UDP streams used to provide an inter-PINX user connection (UQ-channel) is established as H.323 logical channel(s). 

An IPL may have multiple UQ-channels. 
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Figure 2 illustrates these concepts. 
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Figure 2: H.323 as Intervening Network (IVN) 

IPCs in support of these scenarios can be established and released at any time under the control of either PINX. In case 
of IPC failure, the H.323 network may reject a call establishment request or release an already established call. 

A single PINX can terminate a multiplicity of IPLs leading to the same and/or different peer PINXs. Each IPL 
comprises a single H.323 call. 

6.3 Relationship with H.323 gateways 

Each PINX connected to another PINX via an H.323 network represents a trunking gateway in H.323 terms. The H.323 
gateway functionality is part of the mapping functions of the PINX. No specific implementation is implied by the 
present document. The gateway function may be fully integrated or decomposed into several components (e.g. media 
gateway controller and media gateway), as explained in ITU-T Recommendation H.323 [6], 

The tasks of the gateway include the handling of user data or media, e.g. packetization/de-packetization, and signalling 
interworking. The latter mainly enables QSIG to be tunnelled over an H.323 call, as specified in more detail in 
subsequent clauses. 

Figure 3 shows an example of the relationship between a PISN call and the underlying H.323 call which provides the 
inter-PINX link for one segment of the PISN call. 
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Figure 3: Example of the relationship between PISN call and H.323 call 

7 Capabilities at the Q reference point 

For each instance of the Q reference point: 

• one signalling channel (Dq) for carrying the inter-PINX Layer 3 signalling protocol; and 

• zero, one or more user channels (Uq) 

are provided. 

NOTE: If the DQ-channel is used only to support QSIG call-independent signalling connections, no Ug-channels 
are required. 
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For a Ug-channel the following bearer capability shall be provided: 

• transfer mode: circuit mode; 

• information transfer rate: 64 kbit/s; 

• information transfer capability: speech or 3,1 kHz audio; 

• user information layer 1 protocol: G.71 1 A or |i law. 

Other bearer capabilities may also be provided (e.g. 64 kbit/s unrestricted digital information, or transfer rates other 
than 64 kbit/s). 

For a Dg-channel the following bearer capability shall be provided: 

• transfer mode: packet mode; 

• information transfer rate: implementation-dependent; 

• information transfer capability: unrestricted digital information. 

The functions to map Dq- and UQ-channels to an inter-PINX connection (IPC) at the C reference point are described in 
clause 9. 

8 Capabilities at the C reference point 

A PINX shall support a packet network interface suitable for multimedia communication according to ITU-T 
Recommendation H.323 [6], The protocol stack shall conform to ITU-T Recommendations H.323 [6], H.225.0 [4] and 
H.245 [5] and shall support protocol tunnelling according to ITU-T Recommendation H.323 annex M.l [7]. 

NOTE: This means that the following protocols are used: 

H.225.0 RAS, if a gatekeeper is present, over UDP/IP; 

H.225.0 call control signalling, with embedded QSIG tunnel, over TCP/IP; 

H.245 within fastStart elements and/or embedded in H.225.0 call control or explicit over TCP/IP; 

- RTP/RTCP over UDP/IP. 

The protocol tunnelling capability of the H.323 call signalling channel serves as the IPC for the DQ-channel. A pair of 
H.323 logical channels for media transport serves as the IPC for a UQ-channel. 

For the on-demand scenario a new H.323 call is established every time a PISN call occurs and cleared when the PISN 
call finishes. 

For the optional semi-permanent scenario the same H.323 call serves multiple concurrent or consecutive PISN calls. In 
this case logical channels are dynamically opened and closed according to the number of Ug-channels required at the 
time. 
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9 Mapping functions 

9.1 General requirements 

For each IPL terminating at a PINX, the PINX shall provide mapping functions for: 

• mapping of the Dg-channel onto a packet mode IPC as provided by the H.323 call signalling channel with 
embedded QSIG tunnel; 

• mapping of the UQ-channel(s) onto the corresponding IPC(s) with an information transfer rate of 64 kbit/s as 
provided by H.323 logical channels (pair(s) of UDP streams). 



9.2 Mapping of the Da-channel 



The signalling carriage mechanism (see clause 6.3 of ECMA-143 [2]) is provided by the protocol tunnelling facilities of 
H.323. There is no layer 2 frame structure. The PINX shall embed a complete QSIG message in the appropriate data 
structure of the transporting H. 225.0 message without segmentation. 

The services and primitives listed in ECMA-143 [2] clause 6.3 can be mapped to the sending and receipt of appropriate 
H. 225.0 messages. Details are left to the implementation. 



9.3 Mapping of the UQ-channel(s) 



The PINX shall map each Ug-channel to a pair of unidirectional H.323 logical channels with suitable transport 

capabilities. The mapping function is responsible for proper packetization, de-packetization, transcoding etc. of media 
data. 

9.3.1 On-demand scenario 

The PINX shall establish a single pair of unidirectional logical channels using RTP over UDP, and assign session 
identifier "1" to it, which shall also be the number of the UQ-channel mapped to this pair. 

NOTE: Other alternatives, e.g. a bi-directional logical channel or multiple UQ-channels for n x 64 kbit/s, are 
outside the scope of the present document. 

9.3.2 Semi-permanent scenario 

For each UQ-channel the PINX shall establish a pair of unidirectional logical channels using RTP over UDP. The 
session identifier "n" assigned to this pair by the master side (in the range 1 to 255) shall be the number of the 
UQ-channel mapped to this pair. See ITU-T Recommendations H.323 [6] and H.245 [5] for more information. 

NOTE 1 : The number of established UQ-channels can be either static or dynamically adapted to the actual call load, 
assuming one channel per call. 

NOTE 2: Other alternatives, e.g. use of bi-directional logical channels or multiple UQ-channels per call in case of 
n x 64 kbit/s, are outside the scope of the present document. 
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10 IPC control procedures 
10.1 Protocol identification 

This clause makes reference to an object identifier identifying the QSIG protocol, here called QSIG object identifier. 
The value of this object identifier is 

{iso (1) identified-organization (3) icd-ecma (0012)private-isdn-signalling-domain (9)}. 



10.2 Registration with gatekeeper 



If a gatekeeper exists in the H.323 domain the PINX shall register as a gateway with its gatekeeper in accordance with 
ITU-T Recommendations H.323 [6] and H.225.0 [4] before sending or receiving any calls. The PINX can detect the 
gatekeeper to register with by using one of the methods described in ITU-T Recommendations H.323 [6] and 

H.225.0 [4]. 

The gatekeeper will then: 

• assist in identifying the peer PINX from a call's destination number; and 

• provide other PINXs with the IP address of this PINX. 

The PINX shall set the terminalType.supportedTunnelledProtocols.id.tunnelledProtocolObjectID to the QSIG 
object identifier in the Register ReQuest message (RRQ) to inform the gatekeeper that it is able to handle QSIG 
signalling. 

1 0.3 Systems without gatekeeper 

In scenarios without a gatekeeper each PINX has to know the IP address(es) of its potential peer(s), e.g. through static 
configuration. 

1 0.4 H.323 call establishment 
10.4.1 Call admission 

If the initiating PINX has registered with a gatekeeper and has not received pre-granted admission for outgoing calls in 
the RCF message from the gatekeeper, the PINX shall send an ARQ message to the gatekeeper prior to call 
establishment. 

NOTE 1: ARQ may still be sent in the case of pre-granted admission, too. 

NOTE 2: Pre-granted admissions only make sense if a suitable call signalling transport address is known a priori, 
e.g. the signalling transport address of the GK if all calls are routed via the gatekeeper. 

The ARQ message shall contain: 

• desiredTunnelledProtocol.id.tunnelledProtocolObjectID set to the QSIG object identifier; 

• destinationlnfo with an alias address of the intended destination (i.e. an alias address sufficient to identify the 
peer PINX). The format is implementation dependent, e.g. a number in the form of 
partyNumber.privateNumber or partyNumber.el64Number. 

On receipt of an ACF message in response, the initiating PINX shall attempt to establish the H.323 call according to 
clause 10.4.2. The ACF message may contain the QSIG object identifier in field 

destinationType.supportedTunnelledProtocols, indicating that the destination is a gateway that can act as accepting 
PINX. 
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On receipt of an H. 225.0 Setup message, if the accepting PINX has registered with a gatekeeper and has not received 
pre-granted admission for incoming calls in the RCF message from the gatekeeper, the PINX shall send an ARQ 
message to the gatekeeper. On receipt of an ACF message in response, the accepting PINX shall accept the H.323 call 
request subject to conditions described in clause 10.4.3. 

If admission fails the accepting PINX shall reject the H.323 call. 

1 0.4.2 Outgoing call establishment 

The initiating PINX shall send an H. 225.0 Setup message to the call signalling address received in the ACF message or 
known a priori. The Setup message shall contain: 

• the sourcelnfo.supportedTunnelledProtocols.id.tunnelledProtocolObjectID field set to the QSIG object 
identifier; 

• optionally fastStart elements as required for the immediate provision of logical channels; 

• called party number information, e.g. copied from the ACF or the QSIG SETUP message, according to H.323 
rules (i.e. Called party number information element or element destinationAddress); 

• optionally the element tunnelledSignallingMessage with the QSIG object identifier in tunnelledProtocolID, 
the complete QSIG SETUP message in messageContent, and tunnellingRequired either present (if H.323 
interworking is not possible) or absent (if H.323 interworking is possible). 

NOTE 1 : If fastStart is not included H.245 procedures can be used later on to open the required logical channels. 

NOTE 2: If supported, the initiating PINX can use H.323 interworking as a fallback if QSIG tunnelling is not 
possible. This is outside the scope of the present document. 

Further call establishment shall follow H.323, H. 225.0 and H.245. If successful, the logical channel(s) opened for the 
H.323 call shall be mapped to UQ-channel(s) as specified in clause 9.3, and the PINX shall be prepared to send and 
receive tunnelled QSIG messages according to clause 10.5. 

1 0.4.3 Incoming call establishment 

A gateway receiving an H.225.0 SETUP that was sent according to clause 10.4.2 shall accept the H.323 call if: 

• the gateway is able to handle the call (no resource constraints, admission granted); and 

• tunnelling of QSIG is supported, i.e. the gateway can act as accepting PINX. 

Call processing shall then follow H.323, H.225.0 and H.245. In addition an embedded QSIG SETUP message shall be 
passed to QSIG protocol control. The gateway shall also include the QSIG object identifier in 

destinationlnfo.supportedTunnelledProtocols.id.tunnelledProtocolObjectID in all H.225.0 messages sent back to 
the originating side up to and including Connect. Logical channels shall be opened by means of fast connect if required 
by the presence of fastStart elements in the received Setup message. 

NOTE: If fastStart is not present H.245 procedures can be used later on to open the required logical channels. 

The PINX shall be prepared to send and receive tunnelled QSIG messages according to clause 10.5. 

If the gateway does not support QSIG tunnelling and an embedded QSIG SETUP message was present with the 
tunnellingRequired flag set the H.323 call shall be released according to H.323. 

1 0.5 Transfer of inter-PINX signalling information 

QSIG messages shall be passed between the two peer PINXs according to ITU-T Recommendation H.323 
annex M.l [7], embedded as complete messages in tunnelledSignallingMessage.messageContent of H.225.0 call 
control or H.225.0 Facility messages, together with the QSIG object identifier in tunnelledProtocolID. The sending 
PINX shall embed a single QSIG message in the proper H.225.0 message and transmit the H.225.0 message 
immediately. Only in the semi-permanent scenario a single H.225.0 Facility message may convey several QSIG 
messages - belonging to different PISN calls - at the same time. 
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Segmentation shall not be used. 



NOTE 1 : The present document assumes transparent transport of QSIG messages by gatekeepers in case of 
gatekeeper routed H.323 calls. 

NOTE 2: Since the H.323 tunnelling mechanism allows only a single protocol to be tunnelled per H.323 call no 
other protocol can be tunnelled besides QSIG if the present document applies. 



10.6 H.323 call clearing 



The H.323 call shall be released from either side according to H.323. Clearing of the H.323 call terminates the IPCs 
provided by that call. Therefore clearing shall only be initiated if no PISN call using these IPCs is in the active state. 

After clearing of the H.323 call, the PINXs should not unregister from their gatekeepers as long as they are ready to 
establish new calls. 



1 1 Scenario specific procedures 
11.1 On-demand scenario 

When required by the presence of a PISN call request, the preceding PINX shall establish an H.323 call towards the 
subsequent PINX as described in clause 10.4, embedding the QSIG SETUP message in the H.323 Setup message. 
Further QSIG messages shall be exchanged according to clause 10.5. 

The Channel identification information element in the embedded QSIG SETUP message shall include the UQ-channel 
number as specified in clause 9.3.1; the call references in the H. 225.0 Setup message and in the embedded QSIG 
SETUP message are independent of each other. 

If call admission procedures apply the preceding PINX shall include the received called party number in the 
destinationlnfo field of the ARQ message. The preceding PINX shall reject the PISN call if admission fails or the 
H.323 call cannot be established for any other reason. 

The H.323 call shall remain active during the lifetime of the PISN call. At the end of the PISN call the H.323 call shall 
be cleared by either side (usually by the side sending the final QSIG call clearing message). 

If the H.323 call fails and recovery cannot be achieved the PINX detecting the failure shall clear the PISN call locally. 
H.323 recovery procedures are an implementation matter outside the scope of the present document. 

The procedures above shall also apply in the case of a connection oriented bearer independent signalling connection. 
The corresponding H.323 call shall be established as a call independent signalling connection (see ITU-T 
Recommendation H.323 annex M.l [7]). Logical channels are not required. 

A UQ-channel shall be established as required by using the logical channel procedures of ITU-T Recommendation 

H.245 [5]. Usually a Ug-channel requires the opening of two unidirectional logical channels, one in each direction, 

although the use of a single bi-directional channel is possible under certain circumstances (see ITU-T Recommendation 
H.323 [6] for details). The fast connect procedure of H.323 shall be the first choice for opening logical channels. H.245 
tunnelling or a separate H.245 channel are only needed if fast connect is not possible or if more extensive H.245 
signalling is required. All open logical channels shall be closed when the PISN call is released. If a logical channel 
cannot be opened or is closed unexpectedly the PINX detecting the problem shall clear the PISN call. 

The parameters used when opening the logical channels are outside the scope of the present document but shall be 
chosen according to the required bearer capability of the Ug-channel. 

If the PISN call is cleared as a result of QSIG restart procedures the H.323 call shall also be released. 
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11.2 Semi-permanent scenario 



An H.323 call may be established between two PINXs independent of a PISN call, using the procedures of clause 10. 
This H.323 call can be used for multiple PISN calls between the two PINXs, both simultaneously and consecutively. 
The maximum number of concurrent PISN calls is an implementation issue. 

The Channel identification information element in an embedded QSIG SETUP message shall include the number of the 
UQ-channel to be used as specified in clause 9.3.2; the call references in the H. 225.0 message and in the embedded 
QSIG message are independent of each other. The call references of the QSIG messages are used to distinguish between 
different PISN calls. 

NOTE 1: The QSIG call references are unique within the context of the underlying H.323 call. Multiple H.323 calls 
over the same interface will have different callldentifier values. 

A PISN call can be established from either side by embedding the QSIG SETUP and all subsequent messages in 

H. 225.0 Facility messages. All QSIG messages will be transported in H. 225.0 Facility messages, i.e. no QSIG SETUP 

message will be embedded in the H. 225.0 Setup message. 

All Ug-channels shall be established by means of H. 245 logical channel procedures. UQ-channels shall be added or 
dropped dynamically as needed, on a per-PISN-call basis, using either H.245 tunnelling within H. 225.0 messages or a 
separate H.245 connection. 

NOTE 2: Each PINX has to open one unidirectional logical channel (the one it intends to transmit on) of the pair 
comprising a UQ-channel. 

The H.323 call can be maintained as long as desired even if no PISN calls are active. 

If the H.323 call fails and recovery cannot be achieved this terminates the IPL. Any PISN calls active at the time of 
failure shall be cleared. H.323 recovery procedures are an implementation matter outside the scope of the present 
document. 

If a logical channel required for a PISN call cannot be opened or is closed unexpectedly the PINX detecting the problem 
shall release the PISN call. 

The H.323 call shall not be cleared as a result of QSIG restart procedures, but resources that are occupied by the PISN 
call(s) affected by the restart shall be released. 
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Annex A (normative): 

Implementation Conformance Statement (ICS) Proforma 



Notwithstanding the provisions of the copyright clause related to the text of the present document, ETSI grants that 
users of the present document may freely reproduce the ICS proforma in this annex so that it can be used for its 
intended purposes and may further publish the completed ICS. 



A.1 Introduction 

A.1 .1 Purpose of an ICS proforma 

The supplier of an implementation which is claimed to conform to the present document shall complete the following 
Implementation Conformance Statement (ICS) proforma. 

A completed ICS proforma is the ICS for the implementation in question. The ICS is a statement of which capabilities 
and options have been implemented for a given specification. 

The ICS can have a number of uses, including use: 

• by the implementor, as a check list for implementations to reduce the risk of unintended non-conformance, e.g. 
through oversight; 

• by the supplier and acquirer, or potential acquirer, of the implementation, as a detailed indication of the 
capabilities of the implementation, stated relative to the common basis for understanding provided by the present 
document's ICS proforma; 

• by the user or potential user of the implementation, as a basis for initially checking the possibility of 
interworking with another implementation - while interworking can never be guaranteed, failure to interwork can 
often be predicted from incompatible ICS; 

• by a tester, as the basis for selecting appropriate tests against which to assess the claim for conformance of the 
implementation. 



A.2 Instructions for completing the ICS proforma 
A.2.1 General structure of the ICS proforma 

The ICS proforma is a fixed format questionnaire divided into sub-clauses each containing a group of individual items. 
Each item is identified by an item reference, the description of the item (question to be answered), and the reference(s) 
to the clause(s) that specifies (specify) the item in the main body of the present document. 

The "Conditions for Status" column contains a specification, if appropriate, of the predicate upon which a conditional 
status is based. The indication of an item reference in this column indicates a simple-predicate condition (support of this 
item is dependent on the support marked for the referenced item). 

The "Status" column indicates whether an item is applicable and if so whether support is mandatory or optional. The 
following terms are used: 

I informational, irrelevant or out-of-scope - this capability is outside the normative scope of the 

present document to which this ICS proforma applies and is not subject to conformance testing in 
this context; 

M mandatory (the capability is required for conformance to the present document); 

N/A not applicable - in the given context, it is impossible to use the capability; no answer in the support 

column is required; 
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O optional (the capability is not required for conformance to the present document, but if the 

capability is implemented it is required to conform to the specification in the present document); 

0.<n> qualified optional - in this case, <n> is an integer that identifies a unique group of related optional 

items; if no additional qualification is indicated, the support of at least one of the optional items is 
required for conformance to the present document; otherwise, the qualification and logic of the 
selection among the optional items is defined below the table explicitly; 

X excluded or prohibited - there is a requirement not to use this capability in a given context. 

Answers to the questionnaire items are to be provided in the "Support" column, by simply marking an answer to 
indicate a restricted choice (Yes, No or N/A). In specific cases, the indication of explicit values may be requested. 
Where a support column box is left blank, no answer is required. 

If a "prerequisite line" (see clause A.2.4) is used after a clause heading or table title, and its predicate is false, no answer 
is required for the whole clause or table, respectively. 

A.2.2 Additional Information 

Items of Additional Information allow a supplier to provide further information intended to assist the interpretation of 
the ICS. It is not intended or expected that a large quantity will be supplied, and an ICS can be considered complete 
without any such information. Examples might be an outline of the ways in which a (single) implementation can be set 
up to operate in a variety of environments and configurations. 

References to items of Additional Information may be entered next to any answer in the questionnaire, and may be 
included in items of Exception Information. 



A.2.3 Exception Information 



It may occasionally happen that a supplier will wish to answer an item with mandatory or prohibited status (after any 
conditions have been applied) in a way that conflicts with the indicated requirement. No pre-printed answer will be 
found in the Support column for this. Instead, the supplier is required to write into the support column an x.<i> 
reference to an item of Exception Information, and to provide the appropriate rationale in the Exception item itself. 

An implementation for which an Exception item is required in this way does not conform to the present document. A 
possible reason for the situation described above is that a defect in the present document has been reported, a correction 
for which is expected to change the requirement not met by the implementation. 

A.2.4 Further indications of the ICS proforma tables 

In addition to the columns of a table, the following information may be indicated: 

"Prerequisite line" 

A prerequisite line after a clause heading or table title indicates that the whole clause or the whole table is not required 
to be completed if the predicate is false. 

"Qualification" 

At the end of a table, a detailed qualification for a group of optional items may be indicated, as specified in the 
description of the status "qualified optional" in clause A.2.1. 

"Comments" 

This box at the end of a table allows a supplier to enter any comments to that table. Comments may also be provided 
separately (without using this box). 
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A. 3 Identification of the implementation 



A.3.1 Implementation Identification 



Table 1 : Implementation Identification 



Supplier (see note 1) 




Contact point for queries about the ICS (see note 1 ) 




Implementation Name(s) and Version(s) (see notes 1 
and 2) 




Other information necessary for full 
identification - e.g., name(s) and version(s) for 
machines and/or operating systems; System name(s) 





NOTE 1: Only the first three items are required for all implementations; other information may be completed as 
appropriate in meeting the requirement for full identification. 

NOTE 2: The terms Name and Version should be interpreted appropriately to correspond with a supplier's 
terminology (e.g. Type, Series, Model). 

A.3.2 Specification for which this ICS applies 

Table A.2: Specification for which this ICS applies 



Title 


Private Integrated Services Network (PISN) -Mapping 
Functions for the tunnelling of QSIG through H.323 
networks 


Version 


1.0 


Corrigenda Implemented (if applicable) 




Addenda Implemented (if applicable) 




Amendments Implemented (if applicable) 




Have any exception items been required? 


No[ ] Yes[ ] 

(The answer Yes means that the implementation does 

not conform to the present document) (see note) 


Date of Statement 




NOTE: In this case, an explanation shall be given of the nature of non-conformance either below or on a 
separate sheet of paper. 


Nature of non-conformance (if applicable): 
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A. 4 General requirements 

Table A.3: General requirements 



Item 


Question: 
Does the implementation ... 


Condition for 
status 


Status 


Reference 


Support 


A1 


act as initiating PINX? 




0.1 




[]Yes 
[INo 


A2 


act as accepting PINX? 




0.1 




[]Yes 
[]No 


A3 


support the on-demand scenario? 




M 




[]Yes 


A4 


support the semi-permanent scenario? 









[]Yes 
[INo 


A4.1 


maximum number of concurrent PISN calls? 


A4 


I 




Value: 


A5 


support a packet network interface with 
H.323 protocol stack with QSIG tunnelling? 




M 


8 


[]Yes 


A6 


support general mapping requirements? 




M 


9.1 


[]Yes 


A7 


support mapping of the D Q -channel? 




M 


9.2 


[]Yes 


A8 


support mapping of the U Q -channel in the 
on-demand scenario? 




M 


9.3.1 


[]Yes 


A9 


support mapping of UQ-channels in the 
semi-permanent scenario? 


A4 


M 


9.3.2 


[]Yes 


Comments: 



A. 5 Procedures 



Table A.4: Procedures 



Item 


Question: 
Does the implementation ... 


Condition for 
status 


Status 


Reference 


Support 


B1 


support IPC control functions - protocol 
identification? 




M 


10.1 


[lYes 


B2 


support IPC control functions with 
registration with gatekeeper? 




0.1 


10.2 


[lYes 
[]No 


B3 


support IPC control functions without 
gatekeeper? 




0.1 


10.3 


[lYes 
[]No 


B4 


support IPL establishment with GK - call 
admission? 


B2 


M 


10.4.1 


[lYes 


B5 


support IPL establishment - outgoing call? 


A1 


M 


10.4.2 


[lYes 


B6 


support IPL establishment - incoming call? 


A2 


M 


10.4.3 


[lYes 


B7 


support fast connect for L)Q-channel 
establishment? 




0.2 


10.4.2 
10.4.3 


[lYes 
[]No 


B8 


support separate H.245 procedures for 
UQ-channel establishment? 




0.2 


10.4.2 
10.4.3 


[lYes 
[]No 


B9 


support transfer of inter-PINX signalling? 




M 


10.5 


[lYes 


B10 


support clearing of H.323.call? 




M 


10.6 


[]Yes 


B11 


support on-demand scenario specific 
procedures? 




M 


11.1 


[lYes 


B12 


support semi-permanent scenario specific 
procedures? 


A4 


M 


11.2 


[lYes 


Comments: 
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A.6 Coding 



Table A.5: Coding 



Item 


Question: 
Does the implementation ... 


Condition for 
status 


Status 


Reference 


Support 


C1 


include QSIG object identifier in RRQ? 


B2 


M 


10.2 


[]Yes 


C2 


include QSIG object identifier in ARQ? 


B4 


M 


10.4.1 


[]Yes 


C3 


include QSIG-specific H.225.0-UUIE 
element values in Setup or Facility and 
receive them in all messages? 


B5 


M 


10.4.2, 10.5, 
11.1 


[]Yes 


C4 


receive QSIG-specific H.225.0-UUIE 
element values in Setup or Facility and 
include them in backwards messages or 
Facility? 


B6 


M 


10.4.3, 10.5, 
11.1 


[]Yes 


C5 


include and receive all QSIG messages in 
H. 225.0 Facility messages? 


B12 


M 


11.2 


[]Yes 


Comments: 



ETSI 



22 



ETSI TS 1 02 037 V1 .1 .1 (2002-01 ) 



Annex B (informative): 
Examples of message sequences 

List of abbreviations used in the message sequences: 



DL 


Data Link 


PC 


Protocol Control 


MP 


Mapping Function/Gateway 


CR 


Call Reference 


Ch 


Channel number 


cpn 


called party number 



The following convention is used for message names: QS1G and H.225.0/RAS message names are all upper case, 
H. 225.0 call control message names are lower case with the first letter in upper case. 



B.1 Successful call setup 



B.1.1 Enbloc sending 



Figure B.l shows an example message sequence for a successful call between two PINXs where the called party 
number in the original QSIG SETUP message is complete. RAS procedures are optional. The call signalling follows the 
direct call model, i.e. the signalling is not routed via a gatekeeper. 



PC 



DL-DATA-REQ 



(SETUP (CR1,ch1)) 




MP 



PC 



DL-DATA-IND 



(CALL PR0C (CR1, chl)) 



DL-DATA-IND 



(ALERTING (CR1)) 
DL-DATA-IND 



(CONNECT (CR1)) 



Setup (CR2, fastStart, SETUP (CR1, ch.1)) 



Call Proceeding (CR2) 




Facility (CR2, CALL PROC (CR1 , ch1 )) 



4 Alerting (CR2, fastStart, ALERTING (CR1 )) 



Connect (CR2, fastStart, CONNECT (CR1)) 



Media established 



DL-DATA-IND 



(SETUP (CR1,ch1)) 



DL-DATA-REQ 



(CALL PROC (CR1, chl)) 



DL-DATA-REQ 



(ALERTING (CR1)) 



DL-DATA-REQ 



(CONNECT (CR1)) 



Figure B.1 : Enbloc setup, successful call, direct call model, with fast connect 
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B.1.2 Overlap sending 



Figure B.2 shows an example message sequence for a successful call between two PINXs where the called party 
number in the original QSIG SETUP message is not complete. RAS procedures are optional. The call signalling follows 
the gatekeeper routed model. 

Note that due to the large number of options in H.323 there are many more scenarios possible. 



PC 



DL-DATA-REQ 



(SETUP (CR1,ch1)) 




DL-DATA-IND 



(SETUP ACK (CR1, Chi)) 
DL-DATA-REQ 



(INFO(CR1,cpn)) 



DL-DATA-IND 



(CALL PR0C (CR1)) 



DL-DATA-IND 



(ALERTING (CR1)) 
DL-DATA-IND 



(CONNECT (CR1)) 



(Setup (CR2, 



..fastSta-t, SETUP (CR1,ch1 



Call Proc (CR2) 



Facility (CR2, 



Facility (CR2, 



Facility (CR2, 



Alerting (CR2, 



Connect (CR2. 



GK 



MP 



PC 



(Setup (CR3, 



Call Proc (CR3) 




Facility (CR3, 



Call Proc (CR4) 



Facility (CR4, 



S;ETUPACK(CR1, 
Facility (CR3, 



cM)) 



.INFO(CR1,cpn)) 



Facility (CR3, 



CALL PROC (CR1)) 



Alerting (CR3, 



fastStart, ALERTING (Cft1)) 
Connect (CR3, 



...fastStart, CONNECT 
Media established 



(CR1 



(Setup (CR4, 



Facility (CR4, 



Facility (CR4, 



Alerting (CR4, 



Connect (CR4, 
)) 



DL-DATA-IND 



(SETUP (CR1,ch1)) 
, DL-DATA-REQ 



(SETUP ACK (CRl.chl)) 



DL-DATA-IND 



(INFO(CR1,cpn)) 



, DL-DATA-REQ 



(CALL PROC (CR1)) 



^)L-DATA-REQ 



(ALERTING (CR1)) 
j pL-DATA-REQ 



(CONNECT (CR1)) 



Figure B.2: Overlap sending, successful call, GK routed call model, with fast connect 
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B.2 Normal call clearing 



Figure B.3 shows an example of call clearing from the active state. Clearing is initiated from the called side. 
For clearing from the calling side the flow is mirrored. 



PC 



MP 



MP 



PC 



^» 




Active call 




^^ 


DL-DATA-IND 


Facility (CR2, DISCONNECT (CR1 )) 


4 DL-DATA-REQ 


(DISCONNECT (CRD) 
DL-DATA-IND 


Facility (CR2, RELEASE (CR1)) 


(DISCONNECT (CR1)) 
DL-DATA-REQ 


(RELEASE (CR1)) 
DL-DATA-IND 


Rel Com (CR2, REL COM (CR1 )) 


(RELEASE (CRD) ' 
DL-DATA-REQ 


(RELCOM (CRD) 




(RELCOM (CRD) 


-^DRQ G 
DCF^-^ 


iK G 


< DRC>-- 
~-\DCF 



Figure B.3: Normal call clearing by called side 
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